Currently, white lists and black lists are widely used technology, which indicates a corresponding service request should be allowed or denied. For white lists and black lists, the behaviors of a system are predefined, whereby the white lists and black lists can be seen as predefined rules. In reality, the white list and black list rules are applied to a lot of systems or services, such as, operating system, firewall, antivirus software, mail systems, application software, voice call, data communications, data storage, etc. In general, the white list and black list rules are applied to almost all of the applications involving control. If a white list is established, then only users (or IP address, IP packet, mail, etc.) in the white list can obtain the grant of the system to get system services. For example, if a white list is established in a mail system, then mails of users in the white list will pass with priority, and will not be rejected as spam, with increasing security and convenience. If a black list is established, then users (or IP address, IP packet, e-mail, virus, etc.) listed in the black list cannot obtain the grant of the system. For example, in a communication operating system, if a certain user (for example, the user's identifier) is listed in a black list, then it may not be able to get a certain service or all services.
In the prior art, as in IP Multimedia Subsystem shown in FIG. 1, the system includes: User Equipment (UE), Proxy Call Session Control Function (PCSCF), Service Call Session Control Function (SCSCF) and Application Server (AS). User Equipment UE sends INVITE message M1 to PCSCF to initiate a service request. PCSCF sends INVITE message M2 to SCSCF, and then SCSCF sends INVITE message M3 to the AS. Application Server AS checks the white or black list, sends to the User Equipment a response which agrees to provide the service if the User Equipment is in the white list, and sends to the User Equipment a response which refuses to provide the service if the User Equipment is in the black list.
In reality, for certain types of services, whether the services should be provided is determined by the circumstances dynamically. Especially in the IP Multimedia Subsystem, which can offer various services in addition to traditional phone calls, such as, video sharing, unified messaging, unified communication, click-to-conference, multimedia collaboration kits, multiplayer game, friend and relative tracking, virtual PBX, security monitoring, outdoor work team efficiency, multimedia ring back tones, call shield, multimedia caller identification, intelligent call center routing, find-tracking and grouping search, or paid by a third party (the authenticating party), etc. For the above service request, sometimes, it is hard to meet requirements only to use the white and black lists to control. For example, in an instance needing service control by a third party, the white and black lists cannot implement third-party control of the services, and cannot implement real-time control of the services.
The latest practice has proposed a gray list between the black list and the white list. The gray list can intelligently perform service control, for example, it can intercept most of the spam. The gray list requires the service requesting party to re-send the just sent service request. For example, in an e-mail application, it requires the e-mail sender to wait a few minutes (the specific time can be set by the system automatically or by the administrator manually) before re-sending once the just sent e-mail. The gray list is based on the fact that the majority of service requests sent in the form of broadcast is usually sent only once, ignoring the request asking to re-send the service requests after a certain time interval. All service requests that are originally rejected by the application server and are required to be “later re-sent” will enter a gray list filter. If after 10 minutes (the specific time can be set by the system automatically or by the administrator manually), the service request is sent again by a remote server, it will pass without any obstacle, and thereafter a request consistent with this request sender will also pass smoothly.
However, the way hereinabove still has a problem that when a malicious attacker sends a service request again after a specified time, such as 10 minutes, then the system will put the malicious attacker into the white list, so that the system is still unable to accurately determine whether to provide the service to an unknown service requester. Moreover, when the requested service of the requester needs authentication from a third party, for example, the service is managed by a third party, the white and black lists cannot implement third-party authentication.